Currently in the Third Generation Partnership Project (3GPP) specifications of UMTS, the signalling protocols used between the network and the User Equipment (terminal) is divided into Access Stratum (AS) and Non-Access Stratum (NAS) protocols. The Non-Access Stratum protocols (e.g. Session Management (SM), Mobility management (MM), SMS) are terminated in the terminal (UE) and Core network (CN) and are sent transparently via the Radio Access Network (RAN). The Access Stratum protocols (e.g. Radio Resource Control (RRC), Radio Link Control (RLC), Medium Access Control (MAC)) are terminated in the UE and RAN, and are not visible in the CN. Additionally there are Iu signalling between the RAN and CN which is not visible to the UE.
Due to the separation of the Non-Access Stratum and the Access Stratum protocols there is a lot of handshaking between the network and the UE to establish a service.
Since there is a clear split between Access Stratum (AS) and Non-Access Stratum (NAS) functions it is not possible to co-ordinate AS and NAS procedures in an efficient way. This leads to that a typical UMTS procedure e.g. “service activation” involves many message exchanged over the radio interface, causing significant delay to the execution of the procedure.
In most practical situations, there is a need for transmitting data in both directions. One way of achieving full-duplex data transmission would be to have two separate communication channels, and use each one for simplex data traffic (in different directions). If this were done, we would have two separate physical circuits, each with a “forward” channel (for data) and a “reverse” channel (for acknowledgment). In both cases the bandwidth of the reverse channel would be almost entirely wasted. In effect, the user would be paying the cost of two circuits but only using the capacity of one.
A better idea is to use the same circuit for data in both directions. In this model the data frames from A to B are intermixed with the acknowledgment frames from A to B. By looking at the “kind” field in the header of an incoming frame, the receiver can tell whether the frame is data or acknowledgment.
Although interweaving data and control frames on the same circuit is an improvement over having two separate physical circuits, yet another improvement is possible. When a data frame arrives, instead of immediately sending a separate control frame, the receiver restrains itself and waits until the network layer passes it the next packet. The acknowledgment is attached to the outgoing data frame. In effect, the acknowledgment gets a free ride on the next outgoing data frame. The technique of temporarily delaying outgoing acknowledgment so that they can be hooked onto the next outgoing data frame is widely known as piggybacking.
In the recent development of Long Term Evolution and System Architecture Evolution within 3GPP the possibility of piggybacking NAS protocol messages into AS protocol messages has been discussed to enable less hand-shaking between the network and the UE.
The problem with the existing solution is that although piggybacking of NAS protocol messages into AS protocol messages potentially would reduce the amount of signalling between the network and the UE it would require a significant effort in defining the co-ordinated behaviour expected in the UE for all possible (or all allowed) combinations of NAS protocol messages and AS protocol messages. This problem would in practice make piggybacking difficult to achieve.